Security risks, such as allowing unauthorized access to a user's system, are inherent with many on-line activities. Therefore, security mechanisms have been developed to protect users' systems. For example, a user may download an on-demand application from the Internet and execute the application from within the browser. To prevent an unauthorized access to the user's system resources (e.g., a directory on the user's hard disk), the user's system is protected by “sandbox” security that is enforced within the browser environment. Sandbox security involves a limited, secure area of computer memory in which an application may execute, so that the application is prevented from accessing system resources that reside outside of the secure area.
In some circumstances, however, a user may wish to allow a downloaded application controlled access to certain resources within the user's system. For example, a user may wish to use an on-demand word processing application to generate a document and then save the document to a directory in the user's system.
Existing approaches for providing such applications with secure, controlled access to a user's system are too cumbersome and inflexible. In one method, for example, a security policy is defined within a policy database in which a given application is associated with a permission set. The security policy, in combination with origin information, signature information, and access restrictions, helps define a “trusted” relationship between the application and the user's system.
Consider the following example:
grant codeBase “http://www.BobsWidgets.com”signed by BobsCertificate {permission lang.io.FilePermission “/tmp/” “read”;permission lang.io.FilePermission “/tmp/bwdir/*” “write”;}
In the example, an applet from the source location, “www.BobsWidgets.com”, is granted certain file access permissions if it is signed with a private key corresponding with a public key contained within BobsCertificate. An applet is traditionally a program designed to be executed from within a browser, rather than directly from within the operating system. The applet is granted permission to read files from the “/tmp” directory on the host system and to create and write to files in the “/tmp/bwdir” directory. Permission to “execute” is another common permission modifier. Other security policy specifications may, for example, grant broad permissions to access any file in any system location, regardless of the application's source or whether the application is unsigned or signed.
In such approaches, security policies are particularly static, remaining fixed over long periods of time. As on-demand application processing via the Internet becomes more prevalent, substantially static security policies are too limiting. Furthermore, the infrequent security policy changes that do occur (usually performed by a system administrator) can introduce security weaknesses or gaps, or prevent authorized applications from running by denying access to an application that had previously been granted access. As such, existing security architectures fail to dynamically and flexibly determine whether an application (or a given code assembly of an application) may be trusted with some amount of access to the user's system.